Supplementary File 2 Graphics Processing Units and CUDA

In the context of high-performance computing (HPC), the traditional solutions for distributed architectures are represented by computer clusters and grid computing [10]. The former exploits a set of inter-connected computers controlled by a centralized scheduler, while the latter consists in the logical organization of a set of geographically distributed (heterogeneous) computing resources. In both cases, the overall computational task is partitioned into smaller sub-tasks, which are assigned to the various computing units for parallel or distributed computation. These infrastructures are particularly appealing because they usually require minimal changes to the existing source code of some given program: as a matter of fact, the computing units are generally based on classic architectures (e.g., the x86 instruction set, typical of personal computers), so that the code can be easily ported, with the exception of possible modifications required for message passing. Moreover, both architectures support the Multiple Instruction Multiple Data (MIMD) execution paradigm, that is, all computing units are independent, asynchronous, can work on different data and execute different code. Despite these advantages, computer clusters and grid computing have considerable drawbacks. On the one hand, computer clusters are expensive, require maintenance and are characterized by relevant energy consumption. On the other hand, grid computing [8] is generally based on volunteering, whereby computer owners donate resources (e.g., computing power, storage) to a specific project [2, 3]. Several factors may further affect grid computing, notably the fact that remote computers might not be completely trustworthy: potentially unpublished data are transmitted to unknown remote clients for processing, and returned results might be intentionally erroneous or misleading. Moreover, there is no general guarantee about the availability of remote computers, so that some allocated tasks could never be processed. A third way to distributed computation is the emergent field of cloud computing, in which private companies offer a pool of computation resources (e.g., computers, storage) attainable on-demand and ubiquitously over the Internet. Although cloud computing mitigates some problems of classic distributed architectures—like the costs of the infrastructure and its maintenance—it is characterized by other problems, mainly the fact that data are stored on servers owned by private companies. This brings about issues of privacy, potential piracy, espionage, continuity of the service (e.g., due to some malfunctioning, DDoS attacks, or Internet connection problems), international legal conflicts, data lock-in, along with typical problems of Big Data, e.g., transferring terabyte-scale data to and from the cloud [4]. In the latter years, a completely different approach to HPC gained ground: the use of general-purpose multi-core devices like Many Integrated Cores (MIC) co-processors [23] and Graphics Processing Units (GPUs) [18]. Noteworthy, both types of devices can be installed on common consumer computers and are characterized by a large number of computing cores (up to 61 for MICs and 5760 for GPUs, at the time of writing). MICs are characterized by cores based on the x86 instruction set, extended with 512-bit vectorial instructions, inter-connected by means of a ring bus. Thanks to this architectural choice, any existing code developed for Central Processing Units (CPUs) should be easily ported to the MIC architecture. In addition, MICs offer two main programming models: the native model, which allows the execution of the source code directly on the MIC, exploiting the multiple cores for parallel execution, and the heterogeneous offload model, which allows to use simple compiler directives to designate the code sections that are executed on the MIC, while the rest of the code runs on the CPU. Differently from MICs, GPUs are pervasive, relatively cheap and extremely efficient parallel multi-core